This PR fixes a bug where custom getTask and getTaskResult handlers registered via registerToolTask were never invoked. The Protocol class's task handlers bypassed them entirely and used TaskStore directly. This was a refactoring oversight that was missed due to (1) the existing tests not explicitly checking if those handlers were called, and (2) setTimeout being used in createTask in many tests inadvertently masking the issue.

This also removes the argument-forwarding to getTask and getTaskResult, as that was originally built before the current TaskStore design was finalized, which broke the assumption that the original request would reliably be stored by the implementor. The current TaskStore design allows the Request to be saved, but does not require that, and also exposes no way to directly retrieve it in getTask or getTaskResult (it was possible but no longer intended at the time of the rewrite).

getTask and getTaskResult now only have the extra argument.

Motivation and Context

When using registerToolTask, developers could provide custom getTask and getTaskResult handlers:

mcpServer.experimental.tasks.registerToolTask('test-tool', options, {
    createTask: async (args, extra) => { /* ... */ },
    getTask: async (args, extra) => { /* not called */ },
    getTaskResult: async (args, extra) => { /* not called */ }
});

These handlers were never invoked because:

1. The Protocol class's tasks/get and tasks/result handlers directly called TaskStore instead of forwarding to the custom handlers.
2. McpServer's backwards-compat polling wrapper also bypassed the custom handlers
3. Tests used setTimeout to complete tasks and did not explicitly assert on the handlers being called, inadvertently masking the issue since tasks completed regardless of whether handlers were invoked

How Has This Been Tested?

Updated unit tests with stricter/more robust assertions.

Breaking Changes

Yes, due to args no longer being passed to getTask or getTaskResult.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context